feat(collections): create from and read raw schema JSON - #598

What

Adds a raw-JSON escape hatch to the collections API, in both directions, on the sync and async clients:

client.collections.createFromJson(json);      // POST /schema
client.collections.getConfigAsJson(name);     // GET  /schema/{name}  -> Optional<String>
client.collections.listAsJson();              // GET  /schema        -> String

Neither direction maps the document onto CollectionConfig. On write the body is forwarded byte-for-byte, so any option the server accepts works — including ones this client version does not model yet. On read the response body is returned untouched.

Why the read side is here too

This started as write-only, but the read path turned out to need the same escape hatch: CollectionConfig deserialization is lossy today, so there is currently no way to render or diff a real collection faithfully using the client alone (see #606 and #607 for the two parsing bugs found while investigating).

Beyond those, also dropped on read: property-level moduleConfig (the server's actual home for skip / vectorizePropertyName), moduleConfig entries that are neither reranker-* nor generative-*, and the read-only shardingConfig fields (actualCount, function, key, strategy).

getConfigAsJson unblocks callers who need the complete picture without waiting for the mapping to be fixed.

Design notes

The raw option is not a parallel set of request classes: GetConfigRequest, ListCollectionRequest and CreateCollectionRequest are parameterized by payload type, so the same request serves both the typed and the raw path.

GetConfigRequest.endpoint(CollectionConfig.class)          // typed
GetConfigRequest.endpoint(String.class)                    // raw
ListCollectionRequest.endpoint(ListCollectionResponse.class | String.class)
CreateCollectionRequest.<CollectionConfig | String>endpoint()

SimpleEndpoint.deserializeClass special-cases String.class by returning the response body unparsed, so any endpoint parameterized by response type gets the raw option for free. On the write side, a String payload is forwarded byte-for-byte and anything else is serialized first.

Other decisions worth calling out:

• The create endpoint returns Void rather than parsing the echoed configuration into CollectionConfig. Both clients discarded it anyway, and a raw payload may describe a collection CollectionConfig cannot represent, which would have made that parse throw.
• CreateCollectionRequest.collectionNameFromJson reads exactly one key, "class", which the client needs in order to return a collection handle. Both clients call it before sending, so a document that is not a JSON object, or that has no non-empty string "class", raises IllegalArgumentException before the request is sent rather than after a round-trip.
• getConfigAsJson validates nothing — there is no name to extract — and maps 404 to Optional.empty(), matching the typed getConfig.
• create(String) already means "create by collection name", so the new method could not be an overload; hence the distinct names.

Testing

• 13 new unit tests covering endpoint shape, verbatim body passthrough in both directions, 404 → empty, and every createFromJson validation path.
• Two new cases in CollectionsITest exercising create-from-JSON → getConfigAsJson → listAsJson → delete, using a dynamic-index-with-RQ payload.

Full unit suite passes. The integration tests could not run locally (testcontainers fails to initialize in my environment — all pre-existing ITs error the same way), so the new integration test logic was additionally verified by running an identical copy against a live Weaviate 1.38.0: the collection was created from raw JSON, getConfigAsJson returned hnsw.rq.enabled = true intact, listAsJson saw it, and the post-delete lookup returned empty. CI will be the real check on the ITs.